Computer networks have become an essential part of modern life. The convenience and efficiency of providing information, communication or computational power to individuals at their personal computer or other end user device has led to rapid growth of network computing, including internet as well as intranet systems and applications. Computer Networks, Third Edition (1996) by Andrew S. Tanenbaum, which is incorporated by reference herein, describes computer networks in detail.
Most computer network communication uses a layered software architecture for moving information between host computers connected to the network. The layers help to segregate information into manageable pieces. The rules and conventions for each layer are called the protocol of that layer.
One widely implemented reference model of a layered architecture for network computer communication is called TCP/IP. TCP denotes Transport Control Protocol, and IP denotes Internet Protocol. TCP/IP is described in detail in TCP/IP Illustrated, Volume 1: The Protocols (1994) by W. Richard Stevens and in TCP/IP Illustrated, Volume 2: The Implementation (1995) by Gary R. Wright and W. Richard Stevens, both of which are incorporated by reference herein.
TCP transmits data over a TCP connection in packages called segments; each segment comprises many bytes of data plus a header of control information. To ensure reliable transmission of data, TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. TCP assigns a sequence number to each byte transmitted and uses that sequence number in various procedures that guarantee reliability.
When TCP sends a segment, it starts a timer and waits for the other end to acknowledge reception of the segment. If an acknowledgment is not received before the end of the timeout interval, the sender concludes that the segment was lost and retransmits the segment. If the lost segment later arrives at the receiver, it represents a duplicate of the retransmitted segment. Any such old duplicate segment must be identified and discarded or it will corrupt the data transmission.
A sender must know how long an interval to wait for an acknowledgment before concluding that a segment has timed out. The time required to send a segment and receive an acknowledgment, called the round-trip time (RTT), will be greater on a busy connection, so the sender must adjust its timeout interval to reflect changes in network traffic. TCP continually modifies the timeout interval using a statistical analysis of RTTs for segments transmitted recently.
TCP achieves faster rates of data transmission by sending multiple segments before waiting for an acknowledgement. Because segments are not acknowledged individually, the measurement of RTT is not very accurate. The TCP Timestamps option provides a means to achieve more accurate measurement of RTT. This option is described in RFC 1323 is incorporated by reference herein.
The TCP Timestamps option allows the sender to place a timestamp value in every segment. The receiver reflects this value in the acknowledgement, allowing the sender to calculate by a single subtract operation an accurate RTT for each segment. This is called the RTTM (Round-Trip Time Measurement) mechanism.
TCP is a symmetric protocol, allowing data to be sent at any time in either direction, and therefore timestamp echoing may occur in either direction. For simplicity and symmetry, RFC 1323 specifies that timestamps should always be sent and echoed in both directions. For efficiency, RFC 1323 combines the timestamp and timestamp reply fields into a single TCP Timestamps option field which is part of the header for a TCP segment. Use of the TCP Timestamp option is not mandatory; the hosts negotiate the use of the Timestamp option during establishment of the TCP connection.
The timestamp value to be sent in a Timestamps option is to be obtained from a (virtual) clock that RFC 1323 calls the “timestamp clock”. The values of the timestamp clock must be at least approximately proportional to real time, in order to measure actual RTT.
In addition to allowing more accurate RTT calculations, the Timestamps option makes possible a simple mechanism to reject old duplicate segments. As noted above, old duplicate segments must be rejected so that they do not corrupt data transmission. The mechanism for identifying and rejecting old duplicate segments is called PAWS (Protect Against Wrapped. Sequence numbers) and is described in RFC 1323.
PAWS assumes that every received TCP segment (including data and acknowledgement segments) contains a timestamp whose values are monotone non-decreasing in time. The basic idea of PAWS is that a segment can be discarded as an old duplicate if it is received with a timestamp less than (ie earlier than) some timestamp recently received on the connection. In both the PAWS and the RTT mechanism, the “timestamps” are 32-bit unsigned integers in a modular 32-bit space. Thus, “less than” is defined the same way it is for TCP sequence numbers, and the same implementation techniques apply. If s and t are timestamp values, s<t if 0<(t−s)<2**31, computed in unsigned 32-bit arithmetic.
RTTM was specified in a symmetrical manner, so that sender timestamps are carried in both data and acknowledgement segments and are echoed in separate fields carried in returning acknowledgement or data segments. PAWS submits all incoming segments to the same test, and therefore protects against duplicate acknowledgement segments as well as data segments.
TCP connections demand significant processing power from a host computer. To reduce the processing load on a host, TCP connections may be offloaded to a network interface device (NID), such as a network interface card, a port that handles specific connections on a multiport card, or an auxiliary processor for a CPU. U.S. Pat. Nos. 6,226,680, 6,434,620, 6,427,171 and 6,807,581, which are incorporated by reference herein, describe devices and methods for network communication wherein the host allocates some of the most common and time consuming network processes to the NID (“fast-path”), while retaining the ability to handle less time intensive and more varied processing on the host stack (“slow-path”). Commonly, multiple NIDs may be coupled to single host.
In a typical embodiment, the host initiates a TCP connection and then transfers the connection to the NID, which has specialized hardware to perform the data transfer portion of the TCP protocol. If the NID encounters a problem, or if the host decides to take control of the connection, the connection is transferred back to the host. After the host solves the problem or performs some other action concerning the connection, the host may then return the connection to the NID to continue the data transfer. A particular TCP connection may “migrate” back and forth several times between the host and the NID before data transfer is completed and the connection is closed.